1. Field of the Invention
The present invention relates to a method, system, and program for method, system, and program for implementing a remote method call in a network environment including a client and server systems.
2. Description of the Related Art
The Java** Remote Method Invocation (RMI) protocol and other communication protocols, such as the Simple Object Access Protocol (SOAP), provides a framework in which objects on separate computers may communicate over a network. In the Java RMI framework, an object on a server is represented on a client system by a stub or proxy object. Applications running on the clients can call remote interfaces on the stub object that has the same set of remote interfaces defined by the remote object class. The stub object carries out the method call on the remote object. When a stub method is invoked, the stub object initiates a connection with the remote Java Virtual Machine (JVM) containing the remote object and transmits the parameters to the remote JVM using RMI interfaces. The stub object then receives the result of the method invocation and returns the values to the caller.
In the prior art, the caller on the client must include code to handle RMI exceptions that the stub object receives from the remote object and passes to the caller. RMI exceptions include any exceptions resulting from communication problems between the stub and the remote object as well as certain errors in the operation of the remote object reported as RMI exceptions, such as a divide by zero that occurs during the execution of the method on the remote object on the server. This requirement that the calls to the proxy object include “guarding” code to handle the RMI specific exceptions increases software development costs because every caller that invokes methods on the stub object must be additionally coded to handle RMI exceptions.
Further, client-server applications that make frequent calls to the stub objects on the client that require communication with the server may generate significant network traffic that may adversely effect network performance. Further details of the RMI protocol are described in the publication “Java Remote Method Invocation Specification,” Revision 1.7 (Copyright Sun Microsystems, Inc.
Applet programs also use the RMI framework. An applet is often launched from a server over the Internet and executes in a web browser program on the client. An applet can either be unsigned or signed. A signed applet is implemented in a Java archive (Jar) file having a signing certificate. When executing unsigned applets in the client, the RMI framework implemented in the client restricts the applet to only communicate with the server from which the applet was launched, and not any other servers. Thus, within the current RMI framework, unsigned applets can only communicate with the server from which the applet was downloaded and launched, and cannot communicate with any other servers or computers. Signed applets are allowed to communicate with servers other than the server from which they are downloaded and perform Input/Output (I/O) operations on the machine in which they are executing. To work within this programming constraint for unsigned applets, applet developers must assure that any data or code the unsigned applet may need to access from the server be maintained on the server from which the applet was downloaded, even if the server side architecture would be more optimally configured by having the needed data on different machines. One technique to work around this constraint is to include mechanisms in the server from which the applet was downloaded to access the data from another server. However, in all cases, the unsigned applet cannot interact with servers other than the server from which the applet was downloaded, even if such direct applet-to-server interaction would be the most efficient design.
Still further, if a developer incorporates the RMI framework into their programming environment, then migrating to a different communication protocol that may be more suitable than RMI would prove difficult because the developer would have to recode all the client callers that invoked methods on the RMI stub object to remove the RMI specific exception handling code from such callers and then incorporate any specific error exception handling code required by the new protocol. This process of having to recode all classes and callers that previously used the RMI framework and called the RMI stub file could substantially increase the cost and time commitment needed to switch to a different client-server communication protocol.
For all the above reasons, there is a need in the art for an improved framework and architecture to allow applications on a client to execute method on objects in remote systems.